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"Preparing management for MIS" could, to the uninitiated, 
conger up a vision of an executive being made comfortable 
in his easy chair and his data systems manager wheeling a 
cathode ray display device in front of him. This vision 
implies that the executive is sitting back and relaxing 
during the development of his MIS and only before the 
system goes operational will he be taught to use his new 
system. Note that I used the word "uninitiated. 11 You in 
GUIDE and I in my business have been through too many sys- 
tems efforts to know that developing a successful MIS cannot 
be done without the meaningful involvement of the managers 
who will use the MIS, Many cancelled efforts and poorly 
designed MIS attest to this fact. 



Therefore, to develop ar, MIS which will go operational on 
time, do what ic is supposed to, and be accepted by those 
for whom it was designed requires that both top and middle 
management understand, accept, and >1ay their roles in their 
system's development. 



The concept of management involvement is all well and good 
and there Is lots of discussion about it, but what has to 
be done to make it a reality? This talk, which Is based on 
my own experience and knowledge, will first answer the ques- 
tion of what must be done to get management involved in the 
development of their own MIS and then go on to explain how 
to best use this involvement to produce a good MIS, 



The first consideration is that management is going to have 
to spend some time, preferably three days, to learn; a 
logical systems development process that allows for their 
participation in systems efforts; the interacting roles 
they anu the systems people play during these efforts; 
some non-detail techniques to play their roles; arid, most 
important, be so sold on the program that they will put 
into practice what they have learned. 



Before going on I want to stress that this' training is 
primarily systems training, management oriented, and 
delivered in English. Technology is secondary. I 
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believe one of the biggest deterrents to meaningful manage" 
ment involvement is education for non-systems people that 
focuses primarily on binary arithmetic, computer concepts, 
software, what the computer will do for you, hands-on, etc. 
!t either "turns them off" because they equate involvement 
with detail, or makes them into "ADP experts" and, as such, 
get too involved in the wrong things at the wrong time. 



Back to the training program. We see that the first con- 
sideration is having a logical systems development process 
that allows for management 1 s meaningful involvement in their 
own systems efforts. On the opposite page is illustrated 
such a process, called EFFECTIVE DATA SYSTEMS DEVELOPMENT. 



The first activity calls for discovering and documenting 
for the particule.r* system under development its current and 
future problems arid needs. Next, the solutions to these 
problems and needs are formulated and documented generally 
as to how they will be solved, to what degree, and the time, 
money, and people needed to do the job. These system objec- 
tives are approved by both systems and operating management 
before being taken to top management for their approval. 



The current system is then described and documented in 
detail. Guided by the system objectives, the current 
system is diagnosed and reasonable changes that can be 
made to the current system are documented in the design 
guidelines. The design guidelines, which detail and 
redefine the system objectives, are approved by systems 
and operating management and then taken to top manage- 
ment for their approval. 



The detail design of the system is then accomplished and 
the resulting documentation Is called the design specifi- 
cations. As with the system objectives and design guide- 
lines, the design specifications are approved first by 
systems and operating management and then by top management. 



Approval of the design specifications triggers the programming, 
testing, and debugging effort and also the training of the 
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The Process of EFFECTIVE DATA SYSTEMS DEVELOPMENT 



Act ivi ty 



Documentation 
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operating personnel. When these are completed the system 
is converted. 



At this point I am sure you are intellectually agreeing 
that this is a good process for systems development. Also, 
I am sure you will agree that most systems efforts are not 
done this way. I would like to submit that most efforts 
begin with some firm idea of the solutions before all of 
the problems are known and where little analysis and design 
work are done before programming. It is during the pro- 
gramming that the lack of good problem definition catches 
up with the effort in the form of changes and additional 
requirements. Consequently, programming becomes a process 
of constant analysis, design, programming, change, reanaly- 
sis, redesign, reprogramming, etc. 



Finally a system goes operational and does not do what it Is 
expected to; heavy maintenance and redesign work is done and 
eventually the system settles down to something acceptable 
to the operating people. It is amazing, but this Is typical 
of the history of what most people call their "successful" 
systems and, sad to say, this is what many operating and 
systems people think must be endured to have any automated 
system. Well, it does not have to be this way, and there 
are success stories to back up this statement. 



We have already looked at a logical process of systems devel- 
opment, now let's consider the interacting roles that opera- 
ting and systems people play throughout that entire process. 



First, for every systems effort a formal or informal systems 
team should be established, composed of systems and opera- 
ting people. Individually these team members represent their 
own departments and collectively they are responsible for the 
systems effort. The team leader will also iopresent top 
management. Note that the team Is primarily responsible 
for the effort, not the systems or operating departments. 



Second, the work carried on by the operating people should 
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be meaningful! which means that they should not be expected 
to know and do the kind of detail work performed by systems 
analysts and programmers. Throwing them into that kind of 
work, for which they are ill prepared, will see them either 
drift off the team or, if they stay, become estranged from 
their home departments. The reason for the latter is that 
the operating people back in their department will look upon 
them as "traitors" who have become just like the people in 
the Data Processing Department. 



One of the most meaningful jobs for the operating team mem- 
bers is to maintain an open line of communication between 
the team and their bosses and co-middle managers back in 
their departments. Through this medium, operating manage- 
ment will be constantly updated as to progress and/or 
problems of the team. Also, management will be meaning- 
fully involved when their representative encourages them 
to make relative suggestions and decisions. Mote that 
this communication is constant throughout the effort. 
Therefore, these relative suggestions and decisions will 
be considered as design inputs not as cause for delay, 
redesign, and reprogramming. The open 1 i ne of communica- 
tion also applies to the systems members of the team who 
are keeping their bosses, the programming manager, and the 
computer operations manager apprized of what is being con- 
sidered and allowing them, as well, to offer suggestions 
and make decisions. 



In addition to being corrmun i cators , the operating members 
of the team will help in defining the problem, establishing 
the system objectives, design guidelines and design specl- 
ficatlons,, They will be of material help in some of the 
areas peripheral to the automated portion of the MIS, such 
as: manual system changes, policy changes, reorganization, 

validating existing files, training, developing better 
supervision and operating controls, etc. Also, because of 
their presence, the man and the machine portions of the 
system will be designed concurrently. This concurrence is 
important. Today most poorly functioning MIS were designed 
first as automated systems and then consideration was given 
to the people part of the MIS. 
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In addition to their Job as communicators and non-detail 
computer system designers, the operating members of the 
team will be primarily responsible for the training and 
briefing of the operating personnel. This training will 
be done prior to conversion during the time when the 
computer programs are being writcer: and tested. Having 
the operating members of the team train their own people 
goes a long way toward reducing resistance t Q change in 
the operating department. 



Up to this point we have highlighted the process of systems 
development and the interacting roles that operating and 
systems personnel play In that process, let's get into 
a little more detail and discuss just how a systems effort 
should be started. This is very important because many of 
our current-day failures can be traced back to a poorly 
conceived beginning. 



In this connection, I want to discuss three very common 
concepts that I believe are injurious to good MIS develop- 
ment. These are: initiating the systems effort by des- 

cribing the present system In detail; initiating the 
systems effort by first researching the company's objec- 
tives, policies, long-range plans, etc.; and, asking manage- 
ment to state their information requ i rements . Note that I 
said that these three practices were injurious to good MIS 
development , 



When an effort starts with a detail description of the 
present system it gets into too much detail too soon; the 
persons doing the work are soon unable to "see the forest 
for the trees" and, consequently, the information require- 
ments of the system are not determined at the beginning 
but are discovered later in the effort when their inclusion 
into the system are cause for redesign, reprogramming, delay, 
etc. 



Appreciate that I am saying not to begin the systems effort 
with a detail description of the present system but to do 
this description after the problems and solutions have been 
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generally defined. The added benefit of describing the pre- 
sent system after the system objectives have been approved 
Is the analysts will detail only where It Is felt that there 
will be system change. This means a much more directed ef- 
fort based on good judgments as to what can be done to solve 
problems not just a fishing expedition. 



The second concept which I believe to be injurious to good 
MIS development is initiating an effort by first nailing 
down and documenting the organization^ objectives, goals, 
policies, long-range plans, etc. Again, 1 am not saying 
that this should not be done, ( am saying not to do It as 
the very first step in the systems effort. It should be 
done after the problem definition, during the time when 
the solutions to the problems are being determined. Much 
time will be saved because it will be done in a specific 
context and its being done will insure that the problem 
solutions are travelling in the same direction as the organi- 
zation. Also, with management Involved, getting these 
often nebulous areas defined will be relatively easy. 



The third and most Injurious concept Is the one that says 
that management should define their own information require- 
ments, Theoretically It sounds good; however, In practice 
It does not work. The reason It does not work is that 
management is required to define their own current and 
future information problems and needs relevant to the MIS 
and also to define their solutions to these problems, i.e. , 
the requirement for a monthly report on so and so, I sub- 
mit that management should not be expected to be so sophis- 
ticated that they can systematically define their own problems 
and needs, and they are even less able to translate these 
information problems into system requirements. 



The proof of what I am saying is in the countless number of 
requirement letters, signed in blood by operating management, 
that are mater ial ly changed prior to the resulting system 
conversions. Some of those subsequent changes were wrought 
by the operating managers themselves and others by the sys- 
tems department because the stated requirements were M un- 
realistlc." In many cases any similarity between the original 
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requirements and the resulting system are purely coincidental. 



Therefore, 1 suggest that systems people interact with manage- 
ment to help management define their problems. The burden 
is on the operating manager to "cry his heart out" during the 
problem definition with the systems person keeping their inter- 
action in context and out of detail. After the problems have 
been defined the burden will shift to the systems team to 
come up with reasonable solutions. Remember that not al i of 
the solutions burden is on the systems members of the team 
because not all of the solutions to information problems are 
in automation. Therefore, both systems and operating people 
should participate in the problem definition and in formula- 
ting the system objectives. In addition, this meaningful 
participation will continue throughout the entire effort. 

Let's recap: 

° MIS development cannot be done without management's 
meaningful involvement. 

° Management should take the time to understand the 
process of systems development; their roles In this 
process; learn techniques to play tfiei r roles; and, 
most important, be so sold on the program that they 
willingly practice what they have learned. 

° Follow the process of EFFECTIVE DATA SYSTEMS DEVELOP- 
MENT with Its six activities and corresponding docu- 
mentation and three management approval points. 

° Establish a systems team composed of operating and 
systems personnel . 

° Be careful that work assignments given to operating 
personnel be relevant to their knowledge and capa- 
bilities, i.e., no detail systems work. 

° All members of the team should keep the lines of 

communication open to their respective departments and, 
when appropriate, involve both operating and systems 
departments' management by having them offer sugges- 
tions and make decisions. 
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Design the computer portion and the rest of the sys- 
tem concurrently* 

Operating people should train their own personnel, 
one benefit of which will be to materially reduce 
resistance to change. 

Do not begin a systems effort with a detail descrip- 
tion of the present system; do this after the system 
objectives have been approved, 

0 Do not begin a systems effort by documenting the 

organization's objectives, policies* long-range plans, 
etc. Do this after the problem definition and In con- 
junction with the formulation of solutions. 

Do not begin MIS efforts by asking operating management 
for their requirements. Efforts should begin with a 
problem definition prepared primarily by operating 
management aided by members of the systems team* 
Subsequent to defining the problems the solutions 
will be formulated primarily by the systems team 
with advise and consent from operating management. 



Other highlights of this process are: 

1, There Is "open season on changes" from the time the 
system objectives are being formulated to just prior 
to the approval of the design specifications; however, 
once the design specifications have been approved, 
"hunting season is over," 

2, Impasse situations that may occur between operating 
departments and/or the systems departments will be 
recognized and solved prior to the final sign-off 
of the design specifications. Appreciate that this 
process precludes many of the Impasse-type situations 
faced today; however, If they do occur, they are 
argued and solved before programming » not during 
programming, 

3, Under EFFECTIVE DATA SYSTEMS DEVELOPMENT, the design 
specifications will contain much of what is today 
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found in program documentation. This means that all 
of the detail analysis and design work is completed 
prior to programming. Systems management should not 
sign-off on the design specifications unless they~*7eel 
that they contain all of the information necessary to 
allow their programmers to “program in peace." 

4. 51 to 75% of the time in a systems development effort 

will be spent from the initiation of the effort through 
the approval of the design specifications. The remaining 
^9 to 25% of the time will be in programming, testing, 
training and conversion. 



Let us review the major benefits that are being gained today 
by organizations that are: properly employing operational 

people on systems teams, following a step-by-step process of 
systems development and beginning their efforts with good 
problem definitions: 

1. Their resulting systems are more responsive to the 
users because the persons for whom the systems are 
being developed are Involved in such activities as 
defining their own problems, describing their own 
present system, designing the new system and training 
their own personnel prior to the conversion. Many 

. of the problems that might arise during the programming, 
conversion and system ope. ration are precluded by this 
prior Involvement. 

2. Subsequent redesign and maintenance to their systems 
are minimized due to operating department involvement 
in the design of the new system. 

3. Systems development efforts are less hectic and there 
are "no surprises" for the operational departments 
when they review the interim and final designs of 
the new system. This is because the users themselves 
have been participating in and guiding the effort 
from Its inception. Also, "no surprises" helps 
Insure on-tlme conversions. 

A. The conversion and subsequent operation of a new sys- 
tem is smoother because the operating personnel who 
have played a part In its development consider It their 
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own system. This has a favorable impact on the 
personnel of the operating department. They con- 
sider the new system as one designed not by the 
systems department but by their own management, 
a big factor in reducing their resistance to 
change prior to, during, and after the system 
is converted. 

5* Operating management takes a proprietary interest 
in their new system and does not abrogate their 
responsibility toward its automated portion. 

They do not consider the automated portion as 
belonging to the Data Processing Department. Also, 
there is good cooperation between the user depart- 
ments and the computer center during the operation 
of the system. All departments tend to consider 
themselves as belonging to a partnership rather 
than looking at each other as antagonists. 



In closing, management can be prepared for MIS, many have been 
prepared, and there are organizations that are today reaping 
the benefits of on-time, workable, user-accepted systems. 



***** 



The following may also be of interest: 

Speech Reprints (Free) 

n The Process of Effective Data Systems Development ," 
presented at the 1968 Data Processing Management 
Association Convention, 

"How to Unlock the Computers Profit Potential," 
presented at the 1969 Spring Seminar of the Steel 
Valley Chapter of the Association for Systems 
Management , 



(over) 
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"Training Management for MIS," presented in March 1970 
to the Central New York Chapter of the Association for 
Systems Management. 

Additional copies of this speech. 



Textbook ($15.00) 

1 EFFECTIVE DATA SYSTEMS DEVELOPMENT 



Seminar (3-day, in-house and public sessions) 
EFFECTIVE DATA SYSTEMS DEVELOPMENT 



To obtain additional copies of this speech, the other speeches 
or textbook noted above, or information on the seminar, write 
or cal 1 : 

Barnett Data Systems 
Suite 507 - 1010 Rockville Pike 
Rockville, Maryland 20852 
Telephone: (301) 762-1288 
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About two years ago a county government experienced a very 
painful implementation of an automated tax billing system. 
Bills were rendored months late and, when they finally got 
out, a substantial number were wrong and misaddressed. When 
the county auditor W3s asked by a newspaper reporter why all 
this had happened, the auditor's reply was "When you automate 
it is always hell for the first three years," 

I like to tell this story because it highlights two problems 
that continue to face us in the development and operation of 
data systems. One is that most development efforts result In 
systems; that are not well received by the users, miss their 
operational target dates, are difficult to operate, require 
an inordinate amount of redesign immediately after they go 
operational, etc. 

The second problem is that both user management and their 
data processing specialists have gone down this road so many 
times that, like the county auditor, they think this has to 
be endured to have an automated system. 

Well, it just does not have to be this way. Decent, on- 
time data systems can be developed if we just go about it 
In the right way. Moreover, i f we do not go about it in 
the right wav, when we develop our management information 
systems (MIS) , we will be in for more trouble than we have 
had with our other systems efforts. The administrative, 
financial and operating systems we have been working on 
have a manual or automated precedent system to guide us; 
however, with an MIS, there is very little in the way of 
a precedent system. The current systems development pro- 
cesses we employ to improve our administrative, financial 
and functional systems are just not adequate to tackle the 
job of developing an MIS, And, as I said before, these 
current systems development processes are not really ade- 
quate to properly do the jobs we have been doing. 

One thing that has done more to hamper good systems develop- 
ment work Is the absence of user Involvement in the initia- 
tion and development of their own data systems. In some 
cases we can blame management for not responding to this 
request by their systems people and, in other cases we can 
blame the systems people for not requesting this involvement; 
however, pointing the finger at each other is not going to 
get us anywhere at this time. 




As noted before, we can muddle along without management’s 
involvement when we are dealing with precedent-type sys- 
tems; however, this same process for the systems develop- 
ment of an MIS will produce a disproportionate amount of 
fiascos - systems under development that are so bad they 
never go operational - and operating failures - systems 
that go operational and are maintained only to give a nega- 
tive or, at best, a very little return for the time, money 
and people invested in their development and operation. 

1 believe the answer for our current, as well as future, 
systems development efforts is a process of systems de- 
velopment believed in and supported by top management that 
requires the involvement of the persons for whom the sys- 
tems development effort is being conducted. 

The crucial point is how do we get top and middle manage- 
ment to believe in such a program (some systems people, 
too) so that they will take some of their valuable time 
to participate in the development of their own data sys- 
tems . 

The answer is that this particular process for systems de- 
velopment must be sold via an effective training program. 

It is one thing to train management in the basics of data 
processing such as binary arithmetic, programming, com- 
puter concepts, hardware and expose them to the computer 
via "hands-on” training and demonstrations of what the 
computer (and its remote display device) can do. However, 
it is another thing to spend three days with management 
convincing them to mean i ngf u Hy involve themselves in 
the development of their own data systems. Convincing 
them by explaining: 

(1) The process o' systems development from 
initial planning through analysis, design, 
implementation and subsequent evaluation 
of the operating system; 

(2) The interacting roles that both manage- 
ment and systems personnel play throughout 
the entire effort; and. 
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(3) Then offer some systems techriques that 
management can use without taking any 
additional training. 

This latter type of training focuses on what management 
must do to help in the development of their own systems 
and makes them comfortable and willing to do so; whereas, 
the former training stresses mainly what systems people do 
and, in some cases, impedes management's meaningful involve- 
ment* 

To review: 

(1) We have had and continue to have troubles 
developing our precedent-type data systems. 

(2) If we develop our MIS in the same way we 
are doing our other systems development 
work we will be in for even more trouble, 

(3) The majority of the problems in systems 
development stem from the fact that managers, 
top and middle, do not meaningfully involve 
themselves in the development of their own 
data systems. 

(A) To develop good management information sys- 
tems, top and middle management will have to 
be convinced to involve themselves in the 
development of their systems and be trained 
to play their respective roles in the systems 
development effort, 

(5) This is best done by a seminar that focuses on 
systems development not hardware, software, 
hands-on training, and demonstrations of what 
the computer can do for you. 

Let's be more specific about the advantages of management's 
involvement in the development of their own data systems: 

(1) With management involvement, the resulting 
system will be more responsive to the users 
because the persons for whom the system Is 
being developed will be involved in such 
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activities as defining requirements, des- 
cribing their cwn present system, designing 
the new system and training functional per- 
sonnel prior to the conversion. Many of the 
problems that currently arise during the pro- 
gramming, conversion and system operation are 
precluded by management's prior ivolvement, 

(2) Subsequent redesign and maintenance to the 
system will be minimized due to user involve- 
ment in the design of the new system, 

(3) Top management will be more likely to approve 
and support a "joint 1 ' systems effort rather than 
a systems effort proposed by either the systems 
department or the using department, 

(A) The systems development effort will be less 
hectic with much less feedback because there 
will be "no surprises" for the user depart- 
ments when they review the interim and final 
designs of the new system. This is because the 
users themselves will have been participating in 
and guiding the effort from its inception, "No 
surprises" will also insure an on-time conversion 
to the new system, 

(5) The conversion and subsequent operation of the new 
system will be smoother because the users who have 
played a part in its development wHl consider it 
their own system. This will have a favorable im- 
pact on the personnel of the users function. They 
will consider the new system as one designed not 
by the systems department but by their own manage- 
ment, a big factor in reducing their resistance to 
change prior to, during and after the system is 
converted, 

(6) Management will take a proprietary interest in the new 
system and not abrogate their responsibilities toward 
the automated portion of their data system. This 
abrogation is noted when functional management con- 
siders "their" automated systems as belonging to the 
Data Processing Department, In such a ^ase, the pay- 
roll manager would tell the data processing manager 
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that it is his problem (the DP manager's), that 
the time and attendance information is inaccu- 
rate and that he should write the operating 
departments asking for improvements in their 
time and attendance reporting* This is not 
the "mothering, protecting and defending" 
role the payroll manager should be playing* 

Such abrogation of management's responsibi- 
lities leads some to conclude that the man 
who controls the MIS will control the organi- 
zation* 

(7) Last, but not least, is the fact that a sys- 
tems development effort conducted with meaning- 
ful involvement from user management is a much 
more gratifying and less nerve racking experi- 
ence for the associated systems analysts and 
programmers than the kind of experiences they 
now have* This process for systems develop- 
ment will have a material effect on an organi- 
zation's ability to hire and retain good systems 
personnel , 

To review: 

(1 ) Better system* 

(2) Less maintenance* 

(3) Greater chance for project approval, 

(A) Less hectic* 

(5) M No surprises*" 

(6) On-time conversion* 

(7) Reduce resistance to change* 

(8) Subsequent proprietary interest by users* 

(9) Reduce turnover of systems analysts and 
p rog ramme rs * 



What I have just said comes from my own knowledge and experi- 
ence. Less than two years ago 1 began teaching a three-day 
management seminar on systems development. Since then, over 
900 top and middle user and systems management personnel have 
taken this seminar. As a result, various organizations are 
experiencing the benefits previously stated. 

The following will highlight "Effective Data Systems Develop- 
ment," the process that incorporates meaningful user involve- 
ment in the development of their own data systems; 

(1) From inception through conversion the sys~ 
terns development effort will be effected 
by a systems team composed of both user 
and systems personnel. The word is TEAM 
not commit tae. This means that a middle 
manager from the user department(s) wi 1 1 
either be on a full-time or on a regular 
part-time assignment to the systems team. 

(2) All team members, systems and users, are 
their department's representatives. They 
are responsible for keeping their co-middle 
managers and bosses informed of what the 
team is doing and relaying decisions and 
suggestions back to the team. Also, depart- 
ment management has a concomitant responsibility 
to communicate with their team representatives. 

(3) Meaningful involvement of users extends to all 
users who will be affected by the new system. 

User team members are meaningfully involved 
when they do the kind of work on the team 

for which they are qualified due to their 
experience and knowledge of the user de- 
partment's operation. User team members 
are not expected to perform sophisticated 
data processing tasks such as detail analy- 
sis, detail design and programming. 

User management in the departments are 
meaningfully involved when they communi- 
cate with their team representatives, making 
decisions and offering suggestions. 
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(4) Responsibility for the success 01 failure 
of the systems development effort rests 
squarely with the team, not with the sys- 
tems or user departments, 

(5) A systems approach to the total systems devel- 
opment effort Is taken by; 1.) Planning what 
wll! be done, 2.) Analyzing the present system. 
3.) Detailing the new system, 4.) Implementing 
the new system, in that order, 

a, Planning involves defining the problem(s), 
i,e,, problem definition, and then deter- 
mining what can be done to solve the p ro- 
blem(s), i.e,, system objectives, Some 
refer to these two activities as a feasi- 
bility study , 

b, The system being improved is then described 
in detail as to what it is presently doing 
and how It does it, The system's problems 
are also detailed, 

c, The present system just described is then 
diagnosed as to what changes can reasonably 
be made to the present system to meet the 
system objectives. These changes are stated 
"in English" as quantified design guidelines, 

d, The quantified design guidelines are given 
to detail designers (computer designers, 
analysts, programmers, and systems and 
procedures personnel) who detail and complete 
the des ign, 

e, When the completed detail design Is approved, 
the implementation phase begins. The com- 
puter systems personnel program and test 

the computer portion of the system and the 
user representatives train their own opera- 
ting personnel. When both the systems 
testing and training are complete, the 
system Is converted. 
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(6) The above noted tasks fn a systems develop- 
ment effort are performed In the stated order; 
however, there is a messure of feedback in 
every systems effort. This is due mainly 

to mistakes and omissions on the part of 
the systems team, and those that help and 
communicate with them, and changes caused by 
factors which are both internal and external 
to the data system. Feedback has to be taken 
into account when determining the money, 
people and time required for the effort. 

(7) A good problem definition is one that dis- 
covers all of the major problems, needs and 
requirements of the data system and the 
related requirements of other data systems 
that do or should interact with the data 
system being developed. Such a study may 
uncover more problems, needs and require- 
ments than can be currently handled. There- 
fore, in defining the necessary solutions, 
decisions will be made as to what priorities 
to give to each requirement. 

The important point here is that this initial 
effort all but eliminates the possibility of 
an existing requirement man i fest ing v i tsel f 
later on in the systems effort when it will 
cause disruption, delay and confusion, in 
addition, it may point up the need for more 
systems changes than previously thought* This 
can result in a larger initial effort or an 
incremental Implementation of a larger effort 
stretched over a longer period of time, 

(8) Mot all of the solut ions to data problems 

are found in automation. Most practical 
solutions contain combinations of two or 
more of the following: automation, reauto- 

mation, manual system changes, taking certain 
applications off the computer, policy changes, 
training, reorganization and improved super- 
vision and operating controls. 
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(9) In the design phase the detail designers - some 
of whom are brought In to augment the systems 
members of the team - are working concurrently 
on the computer and manual portions of the sys- 
tem* This concurrence is important. Many 
poorly functioning automated data systems are 
designed first as computer systems and then, 
almost as an afterthought, consideration is 
given to the man/machine relationships of the 
user personnel who have to make the system 
work. 

In this phase, the user members of the team 
are consulting the systems personnel on man/ 
machine interface matters, working on detailing 
the policy changes and reorganization, and formu- 
lating their training program for operating per- 
sonnel, The training program will be carried 
out during the implementation of the system. 

(10) Whenever a quantified design guideline cannot 
be met without affecting another guideline, 
the detail designers must come to the systems 
team for the resolution of the trade-off. In 
this way, the systems team will decide all 
applicable trade-offs, thereby insuring that 
there will be "no surprises" for anyone. 

(11) There Is "open season on changes" from the 
time the systems development effort begins 
until the detail design is completed; however, 
once the completed design, is approved for 
implementation, the design is frozen. 

As noted before, throughout the planning, 
analysis and the design phases, the user 
representatives explain and show their 
co-managers and supervision what develop- 
ments are being contemplated by the systems 
team and solicit their comments and sugges- 
tions. These suggestions and comments are 
carried back to the systems team for the 
team's consideration. 
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It is possible that an impasse can be reached 
when two or more participating departments - 
user vs. user or user vs. systems - cannot 
agree on a particular item. At this point 
the team leader will take the conflicting 
parties to higher management for a decision. 

Please appreciate that the whole Effective 
Data Systems Development procedure precludes 
many of the impasse-type situations that 
are now faced in systems development efforts. 

Also, if they do arise, they are handled 
and decided during the planning, analysis, 
and design phases, not during the programming 
effort, which is so often the case today. 

(12) The completed design contains many things that 
are today considered program documentation. 

This means that the analysis and design tasks, 
much of which today is done during programming, 
are already completed at the time the detail 
design is approved. One of the jobs of the 
systems representative is to make sure that 
all of the detail decisions are made prior 
to the approval of the completed design. Before 
the systems department agrees to the completed 
design, they should feel that they have all of 
the information needed to "program in peace." 

As you have probably noticed, I highlighted the phases of sys- 
tems development prior to the programming, testing, training 
and conversion. This was done on purpose because it is during 
the planning, analysis and design phases that virtually all of 
the decisions are made and the majority of the total systems 
development time is spent. Under Effective Data Systems 
Development you could spend anywhere from 5 I to 75 percent 
of the time properly preparing for the programming, testing, 
training and conversion with the remaining 25 to kS percent 
of the time devoted to a smooth implementation. 

I appreciate that many of you are not used to this kind of sys- 
tems effort. Many of your current efforts consist of a little 
planning, a little analysis and a little design and a long 
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programming period. The reason for the long programming effort 
Is that a majority of the programming time is not in programming 
but in analysis and design, or should I say redesign and repro- 
gramming, Much of your present-day redesign and reprogramming 
carried on during the programming phase could be avoided if the 
proper people are meaningfully involved before programming rather 
than having to be involved during programming. 

Therefore, to train management for MIS is to train them In sys- 
tems development. Management must be convinced to meaningfully 
involve themselves in the development of their own MIS, They 
must appreciate that they cannot point their finger at their 
systems people and say "You do it!" It just does not work that 
way. 

You realize that we are talking about a change in attitude. Let 
us effect this attitude change, get some decent management infor- 
mation systems developed and then I would like to return and give 
a talk entitled; "Training Management to Use Their MIS," 
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The following may also be of interest; 

Speech reprints (free) 

"The Process of Effective Data Systems Development," 
presented at the 1968 Data Processing Management 
Association Convention. 

"How to Unlock the Computer's Profit Potential," 
presented at the 1969 Spring Seminar of the Steel 
Valley Chapter of the Association for Systems 
Management. 

Book ($15.00) 



EFFECTIVE DATA SYSTEMS DEVELOPMENT 



(over) 



Seminar (3*day) 



EFFECTIVE DATA SYSTEMS DEVELOPMENT 



To obtain additional copies of this speech, the speeches or book 
noted above or information on the seminar, write or call: 

Barnett Data Systems 
Suite 507 • 1010 Rockville Pike 
Rockville, Maryland 20852 
Telephone: (301) 762-1288 




o 

ERIC 

hmaffamiaaa 




- 12 - 

29 



HOW TO UNLOCK THE COMPUTER'S 





PROFIT POTENTIAL 



Presented at the 1969 
Spring Seminar of the 
Steel Valley Chapter of the 
Association for Systems Management 



by 



Arnold Barnett 
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Last year McKinsey & Company published a very enlightening research report en- 
titled: "Unlocking the Computer's Profit Potential." This report was based on 

a survey of thirty-six large U. S, and European companies rep resent 1 ng. thl rteen 
1 ndust ries. 



In essence, the report states that as far as tech n 1 ca 1 a ch i e vemen t Is concerned, 
the diversity and extent of computer applications are outrunning expectations; 
however, In terms of economic payoff, these current, technically superior appli- 
cations are in real trouble. Costlier hardware, larger and increasingly cost- 
lier computer staffs are only part of the reason for the reduction of the profit- 
ability of each new computer application. This may sound like an example of the 
law of diminishing returns; however, not so because, in reality, the real profit 
potential of the computer has barely begun to be tapped. Therefore, something is 
wrong somewhere. 



The McKinsey & Company report suggests that in the last few years the rules of 
the computer game have been changing but management's strategies have not changed. 
Not long ago management could leave the direction of the corporate computer effort 
largely In the hands of the data processing specialists. This was because of the 
nature of the systems being automated, mostly administrative and financial. No 
longer should this be the case; however, it is. Identification and selection of 
new computer applications are still predoml nantly in the hands of data processing 
specialists who, despite their technical proficiency, are poorly qualified to set 
the course of the corporate computer effort. 



Speaking for myself now, this is generally true. However, management should not, 
by Itself, set the course of the organization's computer effort. They should, In 
partnership with the data processing specialists, play a meaningful role in the 
decision-making process. 



This sounds good; however, "management" is made up of Individuals. How willing 
are individual managers to take over this vital function so necessary to help 
lead their organizations out of the land of diminishing returns into the realm 
of tapping the computer's real profit potential? Managers in most organizations 
are not willing to tackle this function. The prime reason being that they are 
not equipped to do so, and they know it. 
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Today there is a wide gap between management's ability and willingness to assume 
this responsibility and the willingness of the data processing specialists to 
accept more and more responsibility in this area. Therefore, somewhat by default, 
the computer specialists, alone, set the course of the organization's computer 
efforts. 



This wide gap exists because management is ill prepared both in attitude and know- 
ledge to assume this responsibility. Because of the lack of proper preparation, 
management feels secure in hiding behind their own jobs and telling their data 
processing specialists that it is they who are being paid to do systems work, 
not management. In addition, this' "lack of proper preparation means that new appli- 
cations suggested by the data processing specialists are usually approved by 
management without the proper attention being paid to the systems planning and 
financial returns analysis, the two basic ingredients of a successful corporate 
computer program. 



Why are managers so unprepared? Why are most managers unwilling to "grab the 
bull by the horns" and help lead their organizations into the realm of tapping 
the computer's real profit potential? 







The main reason is that in the past, and continuing to this very day, management 
j ' s be}n 9 given either none or wrong education. Managers, whenever they can be 

gotten away to school, are being taught all about computer hardware and soft- 
ware and very, very little about such things as systems planning, cost/benefits 
analyses, systems evaluation, the process of systems development, their role 
; this process, and the specific techniques needed to carry out their roles. 

Management, rather than being taught something that they can effectively use, 

| be ^ n 9 given a sales pitch on "what the computer can do for you." In addition, 

} their class time is being taken up with demonstrations, detail programming exer- 

j cises, and "hands on" experience designed to awe management with the power of 

\ tbe com P uter , understand the operation and "hardships" of the computer shop and 

i be able to talk its language. 

j 

In all fairness, it should be said that the promulgators of this education 
: achieve their goal. Today's management approves larger and larger expenditures 

l for computers and computer staffs and, because of the detail training they 

j received -which at the time was intellectually stimulating but of limited 

j practical value - they do not know how and, therefore, do not wish to actively 

jj an ^ meanl ngful ly involve themselves in their own computer development projects. 

I They do not rea i i ze that they can play a meaningful role without submerging 

l themselves into the technical aspects of systems work. 



J 
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To a certain degree, all of this is good for the data processing manager. As 
more and more computer specialists go it alone in directing their organization's 
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computer efforts, they are being promoted into positions such as "Vice President 
for Management Information" and other such elevated positions with the appropriate 
titles and salaries. 



However, remembering the diminishing returns being experienced by most organiza- 
tions in their computer development projects, the "control" of the organization’s 
computer effort in the hands of computer specialists may prove for them to be 
disastrous. Currently the computer application developments in most organizations 
are beginning to be of the day-to-day operating and information systems variety. 
These are the most vulnerable too, because unlike the financial and administrative 
applications, which for the most part returned a savings in clerical help which 
more than offset the developing and operating costs, the current computer appli- 
cations, especially the MIS systems, are not expected to return an operating profit. 
Their benefit to tho organization is one of increasing management’s efficiency, 
helping to create greater customer satisfaction, providing management with a better 
planning tool, etc. Therefore, if an implemented operating and/or information sys- 
tem fails to meet the requirements of the job, the financial consequences to the 
organization could be severe. Obviously, the person to get hurt in this situation 
would be the one who suggested the system and headed up Its development. 



An example of a development failure is the New York Stock Exchange's Central 
Accounting Service System; an effort of three year's time and three and one-half 
million dollars In development money, was scrapped. There were two consequences to 
this failure, not only was the development money lost but individual member brokers, 
tiring of the delays in the program, developed their own automated accounting systems. 
The time and effort spent by the brokers in developing their own automated account- 
ing systems could have been used to improve their securities handling systems, there- 
by being better prepared for larger volumes of securities. Larger volumes did occur 
beginning last spring and, because of the lack of preparation, there were severe 
problems. For most organizations an analogous systems failure could weli have 
an irreparable Impact. 



Data processing specialists should realize that even though they may be enjoying 
a new found stature, they are also approaching an abyss; the same aloofness that 
management is showing toward helping to direct the organization's computer pro- 
gram Is also helping to contribute to the high cost of Individual computer appli- 
cation developments and, in some cases, to partial or complete systems failure. 



At this point, let us review; 

1, Current, technically superior computer applications are not 
providing the economic payoff of former computer efforts; yet 
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the real profit potential of the computer has barely 
begun to be tapped. 



2. The reason for the reduced economic payoff of current 
computer applications and the delay in tapping the real 
profit potential of the computer is that management has 
abrogated their share of direction of the organization's 
computer effort. Individually, managers are often unwilling 
and incorrectly trained to actively and meaningfully involve 
themselves in the development of their own automated systems. 



3. Management, therefore, approves the suggestions of the data 
processing specialists and also confers upon them the burden 
of implementing their own suggestions. Recognizing this 
responsibility, many organizations have upgraded the position 
of tlie data processing manager, some right into the vice 
presidential level. 



k m Herein may well lie the seeds for the downfall of the data 
processing specialist, because without management's active 
and meaningful participation In the development of thei r own 
operating and/or information systems, such sophisticated 
efforts stand to be, at best, unprofitable, a partial failure, 
or, at worst, a complete failure. 



To begin to derive a practical answer to this problem, let us return to the 
McKlnsey report. The following is a quote from page 31 of that report: 



"In almost every Industry, at least one company can now be 
found that is pioneering in profitable new uses of computers. 

In such companies, our findings suggest, the key to success has 
been a strong thrust of constructive interest from corporate 
operating executives who have put thfcir own staffs to work on 
computer development... 

"We believe that other companies will follow their lead. Indeed, 
It may soon be a nearly universal practice to transfer operating 
staff to computer development projects, either by making them 
members of a project team or by attaching them for a year or 
two to the corporate computer staff." 



This passage tells us two things: 



1. The direction of an organization's computer efforts need 
not be taken over completely by management; this should 
be a joint effort of both the data processing specialists 
and management. . 



2. As for each individual computer development project, 
its success rests, to a large extent, on the active 
and meaningful participation of operating management, 
i.e., representatives from the operating or staff 
departments for whom the computer system is being 
developed. 



If this is true, and the experience of the more successful companies indicate 
that it is, then just how should an organization train its management so that 
they will be prepared and willing to actively *nd meaningfully participate in 
the development of thel r own data systems and be a partner with the data pro- 
cessing specialists in formulating the direction of their organization's 
computer efforts. How can operating executives be convinced that involvement 
in the development of data systems will not submerge them into the depths 
of detail technical activities? The answer lies In having a logical program 
for data Systems development that maximizes the non-techn i cal contributions 
of operating managers, and, also, can be both sold and taught to management 
in a relatively short period of time. 



The remainder of this paper will highlight such a program. This program 
was not something thought up in response to the McKinsey report. It has 
existed since early 196V ond has been taught to over 5Q0 persons from 
Government and industry. In addition, the program is well documented In 
a book entitled; EFFECTIVE DATA SYSTEMS DEVELOPMENT. 



The process of Effective Data Systems Development is depicted on the 
following page. 



1 



SYSTEMS 

PLANNING 




Admittedly, this format is the logical, classical approach to data systems 
development. However, Its strength lies in the overall guiding systems 
principles of the effort and in the techniques of implementing of each of 
its phases. 
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First, let us review the quidlng principles of the process of Effective Data 
Systems Development. 



1. Operating management, the persons for whom the system is 
being developed, will actively and meaningfully involve 
themselves in each of the five phases of their system's 
development effort. The resulting benefits will be: 

a. Top management will be more likely to approve 
and support a "joint" systems effort rather 
than a systems effort proposed by either the 
data processing department or the operating 
department(s) . 



b. The resulting system will be better because 
the persons for whom the system is being 
developed will be actively involved In such 
activities as defining requirements, describing 
the present system, diagnosing the present system, 
and designing the new system. Many of the pro- 
blems that could arise during the programming, 
conversion, and system operation are being pre- 
cluded by the involvement of the operating personnel 
during these initial phases. 



c. There will be "no surprises" for the operating 
departments when they review the final design 
of the new system. This is because their people 
will have been active in the total effort, beginning 
with the study of the problems of the current system 
through the design of the new system. 



d. The implementation of the new system will be 
smoother because the operating people who have 
had a substantial role In its development will 
consider It their own system. This will also 
have a psychological Impact on the personnel 
of the operating department(s) . They will 
think of the new system as one designed not 
by the data processing department but by their 
own management, a big factor in reducing their 
resistance to change. 
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2. The activities Involved In each of these phases will be 
carried out In a sequential fashion, e.g., systems analy- 
sis will come before systems design; they wi i 1 not be done 
at the same. time. 



Feedback is recognized as an integral part of this process 
necessitated mainly to rectify mistakes and omissions and 
adapt to changes affecting the system being developed. 



A, Systems development efforts should be undertaken because 
there is a current and/or future need for improving an 
operation not because someone wants to use a computer. 
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5. When determining the improvements to be made to a system, 
a requirements rather than a capabilities approach should 
be taken. Requirements thinking places Initial stress 
on the system's needs; whereas, capabilities thinking 
stresses the known resources available to fulfill these 
needs. 

i 
J 

For example: Requirements thinking will initially pro- , 

ject all of the system's n .ds without regard to the j 

organization's capability to fulfill these needs; whereas, j 

capabilities thinking will concentrate on what can be 

done to help the system in the three hours of computer | 

processing time available each day. The point Is that | 

even though the system developers who use the require- j 

ments approach will be forced to back off to the three i 

i hours of computer time, the resulting overall system | 

improvements will be much better. j 




6, Last, and possibly the most Important overall guiding 
principle, a system Is being developed, not an appli- 
cation for the computer. This means that the system's 
developers will be looking In at the computer from the 
system, not looking out at the system from the com- 
puter. 
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Let us now examine each of the phases of activity } n a systems development 



Systems Planning 

In the systems planning phase a team of operating people and 
systems people study the problems and needs of a particular 
system. Their Initial effort is to prepare a problem defini- 
tion. The problem defim tionwi 1 1 lead Into a study of the 
possible solutions to these problems and a set of system objec- 
tives are formul ated, Key to the development and extent of the 
system objectives should be comprehensive cost/benefit analyses 
with dollar values “attached" to the benefits. 



When top management reviews the system objectives with supporting 
cost/benefit analyses, they will give a "green light" to the sys- 
tems development effort. At this point a formal systems team 
should be established. This team will be composed of both the 
data processing specialists and management- 1 eve I operating personnel 
from the departments for whom the system Is being developed. It 
should be made clear from the beginnino that this Is a team, not a 
committee, and it will function as such. If the project is large 
enough, team membership may be a full-time activity. The nucleus 
of the team is small. When required, the systems team will call 
upon systems analysts, programmers, internal auditors, operation 
researchers, training specialists, and others to perform the 
required detail work or act as consultants. 



Systems Analysis 

The systems analysis phase immediately follows the planning phase 
and consists of formally describing the present system, diagnosing 
the present system, and developing guidelines for the detailed 
systems design. In each of these activities, the operating people 
are heavily involved. 



A good way to describe any data system is to work from the top 
down and depict each level of activity | n successively increasing 
detail. This method has the advantage of allowing the operating 
members of the systems team to prepare the higher-level descrip- 
tions and to use systems analysts to do the rare detailed lower- 
level descriptions. Two advantages accrue to the systems 



development effort because of thf; use of operating people to 
describe their own system: 



) , They know the present system and its nuances because 
they have worked in it for a period of time. A 
systems analyst from the deta processing department 
could never gain this type of knowledge in the 
relatively short period of time he would have to 
spend analyzing it, especially as an outsider. 

2. As the more detailed levels of the systems descrip- 
tion are being delivered to the systems team by the 
systems analysts, the functional people will review 
them for reasonableness and accuracy and will tie 
them Into the appropriate higher-level charts. 



When the systems description documentation is finished, the systems 
team will use it to diagnose the present system. This diagnosis will, 
in essence determine what changes can reasonably be made to the present 
system to meet the system objectives. This diagnosis will be done in 
light of the current state-of-the-art in computer technology and pro- 
gramming. from this activity will come a set of guidelines to the 
systems designers, which can also be considered a redefinition and 
detailing of the system objectives. 



Systems Design 

The detail systems designers will accept the design guidelines and 
begin the detail design. The designers will design the system the 
way the systems team performed the system description, in levels, 
from the top down. At any point in the design effort where the 
detail designers feel they cannot meet a guideline, the systems 
team will be notified to decide the appropriate trade-off. By 
making the designers clear all major trade-off decisions with the 
systems team, the functional people on the team will maintain their 
active participation and there will be "no surprises" for anyone 
when the design is finished. The functional people will be well 
qualified to do this because of their major role in describing 
and diagnosing the present system and in developing the guide- 
lines for the designers. The product of the detail design is 
the design specifications. 
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In review, the systems development effort appears as follows 
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I mo I ementation Phase 



The implementation phase consists of selecting equipment, If the 
system reouires a new computer! programming, testing and debugging; 
training of the functional staff as to their role in the new system, 
and conversion from the existing system to the new system. In this 
phase, the operating people are most heavily involved in the training 
of their own staffs. It is they who should train their own people 
because they will teach the system in the language that the people 
will understand. Also, because of their own active and meaningful 
involvement In the system's development, they will sell the system. 
The mood of the functional people receiving the instruction will be 
more receptive because one of their own has materially helped in the 
system's development and it is he explaining the system, not some 
outs i der . 



Evaluation Phase 

Immediately after the conversion, a formal evaluation scheme should 
be in operation to measure the operating performance of the new 
system. Performance criteria, those that are most meaningful for 
evaluation, are selected from the design guidelines. These criteria 
will be quantified and a range of acceptable values established. 
Operating performance which fall outside this range will be invest! - 
gated for cause. This formal evaluation scheme has the following 
advantages : 



1, By determining a range of acceptable performance, 
an organisation is, at the same time, determining 
the levels of performance that, if reached, will be 
grounds for investigation as to their cause. This 
pre-thought as to what level of performance is 
worthy of investigation is a major step toward 
reducing over- react i on to that which, at first, 
may appear to be a major deviation. Sometimes, 
the over- reac t i on to what appears to be a problem 
does more harm than the performance deviation itself. 



2, By charting actual system performance as reported in 
the evaluation data, the trends or direction of the 
system will be discernable. This will often lead 
to some short-range systems work and, in addition, 
will be an input to the long-range systems planning 
procedure. 
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In summary, this paper has pointed out: 



1. The need for and the desirability of unlocking the computer's 
profit potential. 

2, For an organization to achieve this, and possibly to save 
Itself from a systems development fiasco, they must actively 
and meaningfully Involve their operating and staff j^anagement 
In the development of their own systems. In addition, manage- 
ment should work in conjunction with the data processing specia- 
lists to chart the future course of the organization's "total" 
computer program. 



3. However, no matter how good this sounds, we are dealing with 

Individual managers and, for best results, they must be properly 
sold and (re)educated so that they will willingly involve them- 
selves in such efforts. This goal can be accomplished If an 
organization employs a program of systems development that maxi- 
mizes the contribution of the operating managers without wallowing 
them in detail and, accordingly, educates them as to the techniques 
of this program. With management actively and meaningfully involved, 
the economic payoff from current and future computer applications 
should rise substantially and, of equal Impact, the probability of 
systems development fiascos will be substantially reduced. 



* * * 



* * 
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Another way of stating the current problem In systems development Is to give 
labels to the following lines: 



I 

l 1 

I 1 



\ 



The first line stands for what can be accomplished with currently available 
computer technology* 

The second line stands for what automation can be accomplished by an organiza- 
tion after accounting for the constraints of time, money, people, space, organi- 
zation , pol I t Ics, etc. 

Sad to say, the third line represents what Is actually accomplished. 

Labeled, the lines look as follows: 



Technical ly Feasible 



Organizationally Feasible 



Actual 



A third way of looking at the current problem of systems development is to 
realize that the sophisticated operating and management systems, which are 
presently being worked on or are being contemplated for the near future, are 
extremely vital to the important day-to-day operations of the company. For 
operating management not to take an active and meanlnqful role In the develop- 
ment of these systems 1$ tantamount to Inviting a total waste of time and 
money or a system which, to their thinking, will be 111 conceived, 111 defined, 
poorly deslqned, hard to Implement, and difficult to operate with. If the 
developed system Is both "big and bad," the financial consequences to the 
organizations could be severe. An example of this Is the New York Stock 
Exchange's Central Accounting Service System. The efforts of three years 
time and three and one-half million dollars In development money were completely 
scrapped. 



Why do organizations continue to Implement 3rd generation systems with first 
generation systems development procedures? 

Thnre are two basic reasons: 

One reason Is that data processing specialists are too equipment 
and programming oriented. They tend to look at each application 
from the computer out, rather than the other way around. They 
do not give enough attention to the computer application as a 
portion of a larger system, a system to which the computer Is 
giving a service. 

The second, and by far the more fundamental, reason for systems 
development troubles Is that the management of the departments * 
the functional people - for whom the system Is being developed 
do not actively and meaningfully Involve themselves In the 
development of their own system. 

There Is no Immediate solution to this problem; however, material Improvements 
can be made. When these Improvements are made organizations begin to see a 
greater return on their Investment In data processing and the line on page 2 
which represents "actual" accomplishment Is substantially lengthened. 

The path to Improved systems development efforts lie In convincing middle and 
top management to employ a program for systems development that places Initial 
emphasis on total system requirements and elicits their active and meaningful 
participation In the development of their own systems. 

How does an organization Implement such a program for systems development? 

As stated before, the biggest area for Improvement In systems work lies with 
the persons for whom the systems are being designed. To gain their acceptance 
of a program which requires their active and meaningful Involvement In developing 
their own systems, the following two-step procedure should be followed: 

1. Hake middle and top management aware of the reasons for 
their attitudes toward data processing, and 

2. Give these same people an education that sells the Idea 
of act I ve and meaningful Involvement - not hardware and 
software training - ancf7 at the same time, gives them the 
tools to carry out thel r roles In a systems development 
effort . 

The major reasons for a negative attitude toward data processing systems develop- 
ment efforts are: 

I. Now, as In the past, operating management and staff specialists 
are effectively controlling their own operations. Their success 
depends on how well they combine technical proficiency In their 



specialists with their political accumen and their ability to 
supervise and motivate their subordinates. Their productivity 
Is, more often than not, determined by limits that they them- 
selves set. They think that the computer, If brought Into 
their operation, will chanqe their time-honored way of doing 
things. 

2. Data processing specialists and the persons they are trying 
to serve find It difficult to talk to each other. This Is 
fostered by the physical separation of the Data Processing 
Department from the operating and staff offices, the sophis- 
tication of the computer, the complex programming needed 

to operate the computer, and the technical language used 
by systems people. It can be safely said that there Is 
an "Understanding Gap" between the data processing specia- 
lists and the persons they are trying to serve. 

3. Many potential data processing customers are concerned that 
If they automate a portion of their operation they will lose 
workers who are presently under their Jurisdiction. They 
equate numbers of subordinates with their importance and 
fall to see how a computer, which takes away people, can 
add to their stature within the organization. 

A. Managers attend formal ADP training programs. As computer 
orientation courses they are good. With regard to explaining 
the roles that managers play In systems development efforts, 
they frequently do more harm than good. Many managers return 
"fired up" about the potential of the computer but possess 
little knowledge of the systems considerations necessary to 
plan for and Implement this "hardware." 

Also, these courses teach managers how to program the computer, 
how to add and subtract In binary and how many characters of 
data can be put on one Inch of magnetic tape. The result Is- 
that the managers fear that active participation In a systems 
development effort will Involve them In this low level of 
detail. 

5. Some top executives have the Idea that all that Is needed to 
automate a system Is a computer and some sharp programmers. 
When an automation effort falls, they tend to blame the Data 
Processing Department, either Ignoring or not realizing the' 
negative effect of their own and the operating department 
manager's non- Involvement In the systems development effort. 
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After making management aware of the reasons for their attitude, proper 
management education should follow. The education that changes the attl 
tudes of management toward meaningful Involvement In systems development 
efforts focuses on three Interrelated objectives: * 

1. The total process of systems development Is M 1 us — 

t rated. This opens management's eyes to the breadth 
of a systems development effort and to the myriad of 
tasks that must be addressed and successfully com- 
pleted. 

2. The respective roles of the data processing specia- 
lists and the functional people are explained. The 
student* learn that there are some systems develop- 
ment tasks they can accomplish by themselves, there 
are many tasks In which they will work with the data 
processing specialists, and some detail or technically 
oriented tasks are strictly within the province of the 
data processing specialists. 

3. They will discover that they can perform "meaningful 
systems work" without becoming professional systems 
analysts. This Is possible because the techniques 
of this procedure are geared to allow for maximum 
meaningful participation by the functional people 
working as a team with the data processing specla- 

TTstsT - 

Th I s «J1 scuss Ion will now highlight a systems development program that 
reduces the data processing specialist's attention to egulpment and 
programming and Increases the meaningful Involvement of the persons 
for whom the system is being developed. Many of the concepts and 
procedures In this program can be adopted on an Individual or group 
basis and profitably fitted Into ah organization's existing systems 
development program. It Is of secondary Importance whether or not 
all of the technlgues discussed In this program are used.’ However, 
as more of the total program Is adopted, the better will be the 
•organization's systems development efforts. 

The Systems Development Process 

A systems development effort Is divided Into five segurntlal phases 
of activity and three major functional activities. 



The five sequential phases of activity are 
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The three major functional activities are: 
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The following Is a brief explanation of each of the systems development 
phases and functions* 

During the Systems Planning Phase, the organization's data or informa- 
tion "problems" are defined, studied, solutions considered, systems 
development objectives formulated, and personnel assigned to work on 
fulfilling the objectives* 

In the Systems Analysis Phase, the present system is documented, diagnosed 
to discover its weaknesses, and guidelines for the new system design are 
formulated* 

The Systems Design Phase consists of taking the design guidelines - from 
the Analysis Phase - and using them as a basis for "constructing 1 the 
new system* 

After the designed system has been approved, the Systems Implementation 
Phase will see new equipment selected and installed (if applicable), 
computer programs written and debugged, system operators trained, and 
the conversion made to the new system* 

When the system begins operating, a formal evaluation procedure Is put 
into effect to monitor the results of the operation. The Systems Evalua- 
tion Phase continues for the life of the system, materially aiding in the 
discovery of both system weaknesses and trends in processing activity. The 
results of these formal periodic evaluations are used In the Long-Range 
Planning for the subsequent system* This latter use of the Systems 
Evaluation is depicted In the feedback line from Systems Evaluation to 
Systems Planning. 

Systems Technology concerns the equipment available for processing and 
transmitting data and the computer programming necessary to operate 
this equipment* 

Systems Economics involves the determination of costs for the development 
and subsequent operation of a system and the management analysis for 
determining the "worth" of a particular system. 

Systems Management concerns the day-by-day management and control of the 
systems development effort and handling resistance to change at all levels 
of the organ! zation* 
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The Roles of the Participants an d the Techniques of a Systems Development 
Effort" 



Systems Planning 

*•«. ins ; I rn%f e r tu :r P ^:::: ^::r s rthr„/urne 

then*forraulate°the ^"objectives and present then, to top management for 
their concurrent*. 

In the contexl of this discussion, top management is relative to the scope 
of the problem, it could be the corporation's president and senior vice 
f l! i t , nroblem were of the scope of a total management Informa- 
tion system! K?5pT3 the probleS does not exceed the boundaries 
of a plant, the plant manager would be "top management. 

ir.trj’ a £,;u£ 

wH I continue through all of the phases of the systems development effort 
with the following benefits: 

1. Top management will be more likely to approve and 
support a "Joint" systems effort rather than a 
systems effort proposed by either the Data Processing 
Department or the operating department Is; . 

2 . The resulting system will be better because the 
persons for whom the system Is being developed are 
actively Involved in such activities as defining 
requirements, describing the present system, 
diagnosing the present system, and designing the 
new system. Many of the problems that could arise 
during the programming, conversion, and s y s ^ 
operation are being precluded by the 1 nvo vement 

. of the functional personnel during these Initial 
phases. 

3. The Implementation of the new system will be 
3 smoother because the functional people who have 
had a substantial role In Its development will 
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consider It their own system. This will also have 
a psychological Impact on the personnel of the 
operating department (s) , They will think of the 
new system as one designed not by the Data Processing 
Department but by their own management, a big factor 
In reducing their resistance to change. 

When top management agrees to the system objectives and qives a "green 
light" to the systems development effort, a Systems Team should be 
established. This team will be composed of both the data processing 
specialists and management level operating personnel from the depart- 
ments for whom the system Is being developed. It should be made clear 
from the beginning that this is a team, not a committee, and it will 
function as such. If the project is large enough, team membership 
may be a full-time activity. The nucleus of the team Is small. When 
required, the Systems Team will call upon systems analysts, programmers, 
and others to perform the required detail work. When appropriate, an 
Internal auditor should also be a member of the Systems Team. 

In review, active and meaningful involvement by operating management In 
their own systems development effort can begin with the "discovery" and 
definition of system problems. A study effort will lead to tentative 
solutions which will be followed by the formulation of system objectives. 

Top management will then approve the systems development effort, the 
proposal for which came from a Joint effort by data processing and functional 
personnel. After approval to proceed has been given, a Systems Team will 
be establ I shed. 



Systems Analysis 

The Systems Analysis Phase Immediately follows the Planning Phase and 
consists of formally describing the present system, diagnosing the present 
system, and developing guidelines for the detailed systems design. In 
each of these activities, the functional people are heavily involved. 

A good way to describe any data system Is to work from the top down and 
depict each level of activity In successively Increasing detail. This 
method has the advantage of allowing the functional members of the Systems 
Team to prepare the higher level descriptions and to use systems analysts 
to do the more detailed lower level descriptions. Two advantages accrue 
to the systems development effort because of the use of functional people 
to describe their own systems 

1. They know the present system and Its nuances 
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because they have worked In It for a period of time. 

A systems analyst from the Data Processing Department 
could never gain this type of knowledge in the relatively 
short period of time he would have to spend analyzing It, 
especially as an outsider. 

2, As the mere detailed levels of the systems description 
are being delivered to the Systems Team by the systems 
analysts, the functional people will review them for 
reasonableness and accuracy and will tie them Into the 
appropriate higher level charts. 

When the systems description documentation Is finished, the Systems Team 
will use It to diagnose the present system. This diagnosis will, in 
essence, determine what changes can reasonably be made to the present 
system to meet the system objectives. This diagnosis will be done In 
light of the current state-of-the-art In computer technology and pro- 
gramming, From this activity will come a set of guidelines to the 
systems designers, which can also be considered a redefinition and 
detailing of the systems objectives. 



Systems Design 

The detail systems designers will accept the design guidelines and 
begin the detail design. The designers will design the system the 
way the System Team performed the system description, In levels, from 
the top down. At any point In the design effort where the detail 
designers feel that they cannot meet a guideline, the Systems Team 
will be notified to decide the appropriate trade-off. By making 
the designers clear all major trade-off decisions with the Systems 
Team, the functional people on i*:he team will maintain their active 
participation and there will be n o surprises for anyone when the 
design Is finished. The functional people will be well qualified 
to do this because of their major role In describing and diagnosing 
the present system and In developing the guidelines for the designers. 
The product of the detail design effort Is the Design Specification, 



In review, the Systems Development Effort appears ss 
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The next step In the process Is the implementation of the design 
specifications. However, before that is discussed, note that there 
is no serious consideration of equipment or programming systems until 
the guidelines to the system design are formulated. This Is done 
purposely to focus initial attention on the Sys tern requirements not 
the ADP requirements. The benefit is that with the kind of design 
specifications this procedure would produce an organization is much 
better prepared to Intelligently select the proper equipment and 
programming to meet its systems needs. 

in addition, this procedure calls for relatively more time being spent 
on the planning, analysis and design phases than is usually done today. 
The benefits of this are that by spending more time at "the beginning," 
less time is spent during the implementation of the system; the selection 
of the equipment will be better; and, when the system begins operation 
it will be much more acceptable and workable. 



implementation Phase 

The Implementation Phase consists of selecting equipment, if the system 
requires a new computer; programming, testing and debugging; training of 
the functional staff as to their role (n the new system, and conversion 
from the existing system to the new system. In this phase, the functional 
people are most heavily involved In the training of their own staffs. It 
is they who should train their own people because tney will teach the 
system in the language that the people will understand. Also, because of their 
own active and meaningful involvement in the system's development, they will 
sell the system. The mood of the functional people will be more receptive 
because one of their own has materially helped in its development and it is 
he explaining the system, not some outsider. 



Evaluation Phase 

Immediately after the conversion, a formal evaluation scheme should be in 
operation to measure the operating performance of the new system. Performance 
criteria, those that are most meaningful for evaluation, are selected. These 
criteria will be quantified and a range of acceptable values established. 
Operating performance which falls outside of this range will be Investigated 
for cause. This formal evaluation scheme has the following advantages: 

1. By determining a range of acceptable performance, an 
organization Is, at the same time, determining the 
levels of performance that, if reached, will be grounds 
for investigation as to their cause. This prethought 
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as to what level of performance Is worthy of Investigation 
Is a major step toward reducing over-reactions to that which 
first appears to be a major deviation. Sometimes, the over- 
reaction to that which appears to be a problem does more 
harm than the performance deviation Itself. 

2. 9y charting actual system performance as reported in the 
evaluation data the trends or direction of the system will 
be dl scernabl e. This will often lead to some short-range 
systems work and, In addition, will be an Input to the 
long-range systems planning procedure. 

This discussion will not describe In detail t he three functional areas of 
technology, economics and management; however, this knowledge Is Important 
to functional management and In the educational program they are amply 
covered. 

In summary, this discussion has pointed out: 

1. The pressing requirement for better "systems development 
efforts , M 

2. The need for: 

a) Data processing specialists to become more 
"systems’ 1 oriented as opposed to ADP oriented. 

b) The active and meaningful Involvement of the 
persons for whom the systems are being developed. 

3. A two-step procedure to gain this involvement: 

a) Make management aware of their attitude toward 
systems development. 

b) Via education, convince middle and top management 
of their role In the process of systems development. 

This Is best done by teaching: 1) The total 

process of systems development. 2) Management’s 
role In this process. 3) The techniques they 
will need to carry out their roles. 

**. The techniques and procedures discussed are considered to be the 
best for doing systems development work with functional people 
actively and meaningfully Involved. However, acceptance of a 
specific technique or procedure Is secondary to the main goal 
of convincing management of their vital role In systems development. 

3 
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5* Lest we forget, this educational program calls for the 
functional people to work with the data processing 
specialists on a Systems Yearn. This Is much better 
than having functional people learn about data pro- 
cessing only to enable then, to understand what the 
data processing specialists are saying and doing. 



* * * * * 
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